The concept of a tuplespace was first described in 1982 in a programming language called Linda, a coordination language for expressing parallel processing based on generative communication. A tuplespace is a logically shared memory or buffer that contains tuples (data entries). A tuple is a collection of ordered type-value fields, such as (integer 11, integer 8, integer 38), (string “to”, string “aa”, string “hi”, string “ss”) or (string “John”, integer 38, decimal 156.7). Each tuplespace functions as a “blackboard” visible to all participants (e.g., software entities) in a particular scope.
A tuplespace model provides inter-process coordination via tuplespaces which are accessed associatively. Active software entities, which may be distributed over physically dispersed machines, can communicate to each other by releasing data (a tuple) into a tuplespace. Tuples may be posted to the tuplespace, or read/retrieved from the tuplespace in either a destructive or non-destructive manner. This means that senders generate data for use by others without needing to know which process will consume it, and consumers of data need not know who created it.
Tuples in the tuplespace are accessed by matching some or all the elements of the tuples to values or types presented in a predetermined tuple. More specifically, consumers request tuples using a template tuple whose field values are specified where an exact match is desired and left as wild-cards where values are desired to be retrieved from the matching tuple. When a match is found, the tuplespace infrastructure returns a matching tuple to the requesting process.
The most important language primitives in tuplespaces are ‘out’ (puts a tuple into the space), ‘in’ (consume a tuple from the space), and ‘read’ (copy a tuple from the space), where the ‘in’ and ‘read’ operations supply a template tuple that may specify explicit values or wildcards for any tuple fields. FIG. 1 shows an abstract representation of how tuplespaces function. In step (a), a sender places a ‘circle type’ tuple using ‘out’, as indicated by (1) and the tuple becomes available in the tuplespace (2). In step (b), a receiver submits a ‘read’ request for the ‘circle type’ tuple (3) and the tuplespace returns a copy of the ‘circle type’ tuple submitted in step (a), as indicated by (4). In step (c), the receiver submits ‘in’ request for the ‘circle type’ tuple (5) and the tuplespace returns a copy of the ‘circle type’ tuple submitted in step (a) and removes the copy in the tuplespace, as indicated by (6).
There are many tuplespace implementations in many languages in various states of development. For example, Sun Microsystems introduced JavaSpaces service specification in October 2000 to provide a distributed persistence and object exchange mechanism for code written in the Java programming language. Objects are written in entries that provide a typed grouping of relevant fields. Using the known two-phase commit model, the JavaSpaces service supports a simple transaction mechanism that allows multiple clients to write new entries, lookup existing entries, and remove entries from the space.
IBM introduced a similar concept via Java-based TSpaces in March 1998. The TSpaces consists of a set of network communication buffers (tuplespaces) and a set of application-programming interfaces (APIs) and classes that implement the API for accessing those buffers. The TSpaces package includes server software that implements the buffers and client software for accessing the buffers. For the client, TSpaces acts as a reminder service, carries out tasks assigned by the client, reports incoming messages and delivers outgoing messages, and notifies the client of events in which the client is interested.
The basic tuplespace model as introduced in Linda was intended to coordinate a set of processes designed to work together as part of a distributed application. In this situation, since no processes are foreign to one another, no heterogeneous application coordination is necessary. As such, implementations of the basic tuplespace model lack support for coordinating heterogeneous application interactions. Even most implementations of extended tuplespace models, such as JavaSpaces or TSpaces, while allowing disparate applications to coordinate, function only for one language, thus making them unsuitable for coordinating applications written in diverse languages for different platforms. For example, both JavaSpaces and Tspaces allow homogeneous applications written in Java to coordinate. This single platform support is only one of many reasons why existing tuplespace implementations are not well suited to coordinate dynamic heterogeneous application interactions in a ubiquitous computing environment. As described herein in a later section, known tuplespace implementations also lack support for many important and/or essential properties that optimize a ubiquitous computing environment.
The term “ubiquitous computing” was coined by Weiser in “The Computer for the 21st Century” Scientific American, 1991, 265(3), pp. 66-75. Since then, it is generally understood that the keys to ubiquitous computing include physical integration with the surrounding environment and spontaneous interaction across devices. To date, however, there is no good model for developing applications that allow for the spontaneous interaction. More particularly, currently there is no viable application coordination infrastructure enabling application portability and extensibility in ubiquitous computing rooms.
Accordingly, there is a continuing need for an application interactions coordination infrastructure for a ubiquitous computing room having heterogeneous software applications running on various networked machines and devices across platforms. The present invention addresses this need.